第3章 関数（Clean Code）
冒頭より、プログラムの中で関数は最初の構成体
関数をうまく書くための方法を解説（結論）
話して聞かせるストーリー
関数は短く
抽出する 👉 名前はスコープに反比例（一度しか使われないものは長い名前でよい）
短い関数でストーリーを語らせると理解
小さいこと！
code:小さい関数の例.py
def render_page_with_setups_and_teardowns(page_data: PageData, is_suite: bool) -> str:
if is_test_page(page_data):
include_setup_and_teardown_pages(page_data, is_suite)
return page_data.get_html()
ケント・ベックのプログラム、2〜4行の関数からなる。明瞭だったとのこと
関数内のインデントレベルは1つか2つ (Kindle の位置No.1277-1278)
読みやすさのため
処理内容を表す名前を付ける
1つのことを行う
関数の名前で示される、ある1つの抽象レベルにおけるいくつかのステップのみで表現されるなら、その関数は1つのことをしています (Kindle の位置No.1299-1300)
「小さいこと！」の例、1つの抽象レベルにおけるいくつかのステップを表している
page_dataがtest_pageなら、include_setup_and_teardown_pagesをする
いずれの場合もpage_data.get_html()を返す
関数を書く＝抽象的な概念を一段階具体化する、と理解した
中から別の関数を抽出できるなら1つ以上のことをしている
1つの関数に1つの抽象レベル
関数の中で複数の抽象レベルのことを一緒に行うと常に混乱を招きます。(Kindle の位置No.1321)
本質的な概念と実装詳細を混ぜない
（本質的な概念って、もしかして『Clean Architecture』で言う"方針"？）
関数宣言の並びとしてプログラムが上から下に読める：逓減規則
switch文
多態（ポリモーフィズム）を使って、低いレベルの処理にのみ用いる
解決策は、switch文を抽象レベルの最下層である抽象ファクトリに置き、人の目に触れないようにする (Kindle の位置No.1367-1370)
ファクトリ内にだけswitch文を置く！
抽象ファクトリはデザインパターンかも
内容をよく表す名前を使う
長い名前
小さい関数
1つのことを行う小さい関数は名前を付けやすい
関数の引数
関数の引数は理想的には0（ニラディック、niladic）です。(Kindle の位置No.1413-1414)
引数は少ないほうがよいという主張
引数の難しさ
引数は実装詳細を知らなければならなくなる
引数の組み合わせを網羅するテストケース
出力引数は理解を困難にする
フラグ引数
関数にbooleanを渡すのはよくない習慣 (Kindle の位置No.1454-1455)
2つのことをしている！
分割するべき
引数オブジェクト
副作用を避ける
コマンド・照会の分離原則
関数は、何らかの処理を行うか、何らかの応答を返すかのどちらかを行うべきで、両方を行ってはなりません。(Kindle の位置No.1568-1569)
戻りコードよりも例外を好む
DRY（Don’t Repeat Yourself）原則
構造化プログラミング
ダイクストラへの言及は『Clean Architecture』を思い出させる
小さい関数
なぜ関数をこのように書くのでしょう？